home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c
- Path: newsfeed.ed.ac.uk!edcogsci!richard
- From: richard@cogsci.ed.ac.uk (Richard Tobin)
- Subject: Re: Restrictions on qsort compare function?
- X-Nntp-Posting-Host: pitcairn
- Message-ID: <DoKJMJ.491@cogsci.ed.ac.uk>
- Sender: cnews@cogsci.ed.ac.uk (C News Software)
- Organization: HCRC, University of Edinburgh
- References: <4iokop$h4p@lyra.csx.cam.ac.uk>
- Date: Wed, 20 Mar 1996 13:47:06 GMT
-
- In article <4iokop$h4p@lyra.csx.cam.ac.uk> jkb@mrc-lmb.cam.ac.uk (James Bonfield) writes:
- >My understanding of this is that qsort() ought to be able
- >to handle any sort function, even if it's something as dumb as
- >(rand()%3)-1.
-
- The standard says that the function must return negative, zero or
- positive according to whether the first argument is less than, equal
- to, or greater than the second. It is implicit in this that the
- comparison function defines a total order on the elements; something
- like (rand()%3)-1, or a<b, doesn't.
-
- The point is that it must be consistent. If qsort() compares two
- elements twice, it should get the same result each time. If a < b
- then b > a. If a < b and b < c then a < c. Neither of the functions
- mentioned above has these properties. In particular if a is less than
- b then a < b will return 1 but b < a will return 0 which is not
- negative.
-
- I suppose this should be made explicit in the standard, if it hasn't
- already been.
-
- -- Richard
- --
- "Hither turn thy steps, hither come to thy death and for Camilla
- receive due guerdon! Shalt thou, even thou, die by Diana's darts?"
- [Virgil, Aeneid X1 855-7]
-